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the Patent and Trademark Office patent file or records, but otherwise reserves all 
copyright rights whatsoever. 

Background of the Invention 
Field of the Invention ' 

The present invention relates to use of polymorphic data in a session between a buyer 
and seller, or any pair of trading partners, mediated by a broker or e-comtnerce hub. In 
particular, methods and devices utilizing a flexible service request and session end messages 
are described. 

Description of Related Art 

A desire for electronic commerce brings trading partners together. Broker or hub 
applications can facilitate transactions between trading partners in many ways. The broker 
application can field an initial session start request from the buyer and forward it to a seller, 
either acknowledging the start of the session explicitly or leaving it to the seller to 
acknowledge the start of the session to the buyer. This and other variations on the manner in 
which electronic commerce is implemented have implications for software design. 

Summary of Invention 

An aspect of the present invention includes a protocol for conveying data during an e- 
commerce session with a polymorphic response, comprising initiating a session with a first 
message from a buyer application to a broker application and a second message from the 
broker application to a supplier application; conducting the session between the buyer 
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application and the supplier application; and responding during the session with an additional 
message which includes a schema identifier for the additional message, resolvable in a 
context of a system identifier and a polymorphic response comprising a type and a version, 
wherein the polymorphic response includes additional data elements corresponding to values 
assigned to the type aiid version. Additional aspects of the invention can be foxmd in the 
detailed description, the figures and the claims. 

Brief Description of Figures 

Figure 1 is a schematic diagram of components useful between buyer and supplier. 
Figure 2 is a schematic diagram of processes firom subscription through purchase 

order. 

Figures 3-6 are schematic diagrams extracted from or resembling figure 3, with 
reduced detail to aid in understanding various processes. 

Figure 7 is an interaction diagram firom beginning with a user's initiation of a session. 

Detailed Description 

The following description of various aspects and embodiments of the invention is 
presented for purposes of illustration and description. The description is not intended to limit 
the invention to the precise forms disclosed. Many modifications and equivalent 
arrangements will be apparent to people skilled in the art. 

One embodiment practicing aspects of the present invention is so-called 
RoimdTrip(TM) software. RoimdTrip facilitates connections between buyers and suppliers 
for connecting via a MarketSite(TM) portal. Other embodiments of the present invention will 
be adapted to facilitating connections between trading partners using other e-commerce 
portals and connections, including OBI compliant protocols . RoundTrip software may be 
delivered as a patch to the XML commerce connector (XCC) software or as a stand alone 
package. Buyers use the XCC software or equivalent components of a stand alone package to 
process polymorphic messages involving the RoundTrip software. Suppliers optionally may 
use the XCC software. Custom adaptations to the RoundTrip software by suppliers are 
supported. The RoundTrip software facilitates return of shopping cart data fi^om a supplier 
application to a buyer application, after the buyer has created the shopping cart at the supplier 
site. The buyer application can then use the shopping cart data to create a purchase order 
which it can send to the supplier application without involvement of the RoundTrip software. 
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One aspect of the present invention, foxind in the RoundTrip software, is use of a 
polymorphic message in the context of an e-commerce session to respond with results during 
a session, sometimes at or near the end of the session. A polymorphic message, described 
further below, is capable by design of returning shopping cart data, product configuration 
data, tax calculation data, foreign freight forwarding data, status inquiry responses or another 
form of data which reflects the interaction between the buyer and supplier. Another aspect of 
the present invention is use of a polymorphic message to initiate a session, the polymorphic 
message being adaptable to sending out purchase orders, purchase order responses, invoices, 
advance shipping notices or the like. 

In presenting the RoundTrip software embodiment, reference is made to buyers and 
suppliers. Buyers and suppliers might altematively be referred to as trading partners. 
Reference to buyers or buyer applications is to be taken in its broadest sense as referring to a 
party or application which seeks goods, services, conraiercial data or the like. Reference to 
suppliers or supplier applications has a similarly broad meaning, referring to the source of 
goods, services or data which the buyer seeks out. The RoimdTrip software itself is referred 
to as the broker application. This software and equivalent applications may sometimes be 
called e-commerce hubs. 

Figure 1 illustrates software components which interact with the RoimdTrip 
software. A firewall 101 surrounds these components. The RoundTrip software may be 
installed as a patch to the XCC software, both represented by 1 12. Other software 
components include an LI router 1 13, an L2 registration 114, and an L2 integrated supplier 
116 with a forwarding service 117. In practicing the present invention, these components of 
Conmierce One's implementation of the present invention are generally interchangeable with 
components of altemative e-commerce systems. Fewer more components can be adapted to 
practicing aspects of the present invention. Software components may be deployed on one or 
more of servers in commimication with each other via a secure (encrypted or physically 
secure) or insecure connection. The LI router 113 routes messages through the portal. It is 
useful for this router to be maintained in a DMZ, allowing it to act as a receiving point for all 
extemal documents and to make HTTP/S connections with suppliers. To route messages, the 
LI router maintains a database of destinations to which it posts messages. These destinations 
can be URL addresses. The L2 registration component 114 handles and maintains 
registration of buyers. The L2 integrated supplier 116 provides the service of forwarding 
message to trading partners. In this case, it forwards the shopping cart received by the broker 
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application, of which it could be considered a part, to the buyer application. The XCC 
software operates at the MarketSite Messaging Layer (MML). Buyer application messages to 
the RoundTrip software are compliant with published MML layer protocols. The RoundTrip 
software can run on the NT operating system platform. It is designed to use MS SQL Server, 
5 Apache web server and JRun. Other embodiments the present invention may be adapted to 
other operating systems, databases, servers and software interpreters or compilers. The 
RoundTrip software may be positioned on the opposite side of a firewall fi*om the buyer 
application, or on the same side. 

Figure 2 is the high-level data flow for the RoimdTrip software. Figure 3-6 are 
10 excerpts or variations of this figure which illustrate various aspects of data flow. A 

RoundTrip user navigates through a sequence of links to arrive at the desired supplier's first 
page. One navigation flow is firom a buyer view, to a RoimdTrip home page, to a service or 
Iq supplier selection page, to a supplier first page. An altemative navigation flow would begin 
from within a catalog, proceeding from a level corresponding to the supplier, product or 

w 

p 15 commodity of interest. The buyer would be routed from the catalog maintained for the buyer 

to a supplier site. The session during which the buyer is in contact with the supplier may be 
'0 referred to as a supplier service session or simply a session. The start and end of the session 

i! 

are handled by the RoundTrip software. The interaction between the buyer and supplier may 

m 

occur directly between the user's web browser and the trading partner's web based service, or 
iil 20 may be relayed through the broker. 

p The following interaction overview can be imderstood with reference to figure 2. 

The supplier 240 registers with the RoimdTrip software 210. This registration to be handled 
manually, through a registration agent, or online. Online registration many the subject to 
manual or off-line verification. On the buyer side, the buyer 230 subscribes to one or more 

25 RoundTrip 210 enabled services. This can be either a manual procedure or an automated 
selection. An automated selection is facilitated by use of compatible software by buyer and 
supplier. Subscription services need to be accompanied by customizations or translators 
when the supplier side software is not natively compatible with the buyer side software. A 
broker session starts when a user of the buyer application 230 initiates a session. This may 

30 include selecting the RoundTrip home page 210. Interaction during a broker session allows 
the buyer to view available services and select a specific service. In altemative embodiments, 
such as for tax calculation, a "buyer" application could automatically invoke the desired 
service through the broker application, without any explicit act of user selection. When the 
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buyer 230 selects the service, a supplier service session start document flows from the broker 
application 210 to the supplier application 240. This docimient may contain both data 
provided by the buyer during the session and data preregistered by the buyer in a registration 
database. This document can be transmitted by an HTTP/S Post, to a supplier provided URL 
5 with an XML format docimient in a hidden field. The supplier provided URL corresponds to 
location with a supplier has a script running that takes the session start docimient and stores it 
a database. The supplier application then does an HTTP redirect to an additional supplier 
URL that is to be seen by the buyer application. Alternatively, the broker application can 
provide the redirect data to the buyer application, for the buyer application to execute the 
10 redirect. The location at which the session start dociunent is stored is forwarded as a 
parameter with the redirect message. This may result in a top-level page of the supplier 
service being displayed on the buyer's browser. In one embodiment of the present invention, 

(□ 

,™ the supplier application at the initial URL discards any cookies received before executing the 

'"^^ redirect with reference to the location where the session start document is stored, to the 

W 

□ 15 additional supplier URL. Use of an HTTP redirect is useful to facilitate proper resolution of 
relative links to the supplier URL by the buyer's browser and to facilitate proper handling of 
cookies issued by the supplier URL to a buyer browser. The buyer and supplier may proceed 

1=^ to interact directly 250. Altematively, their interactions can be routed throught the broker. 

* 3 S 

IZ Upon completion of the session, the buyer ends the interaction with the suppUer application, 

20 for instance by clicking an accept or cancel button. In one embodiment, this results in a 
Q shopping cart commitment or in a cancellation. The supplier application 240 sends a supplier 
service session end document to the the broker 210. When the interaction produces a 
shopping cart, the shopping cart data or are reference thereto is included in the message. The 
broker application 210 next transmits the session details (e.g., shopping cart) to the buyer 
25 application 230. In one embodiment, the broker application does an HTTP post of the 

message to an appropriate buyer application URL, e.g., for a procurement application. In this 
embodiment, the RoundTrip software waits for an HTTP Reply from the buyer application. 
The buyer application 230 may use the order information to create or update a requisition or 
purchase order 23 1 . Without need for interaction through the broker application, the buyer 
30 application may transmit this purchase order through MarketSite software 220 or directly to a 
supplier 240. Special messages can be used in cases of session cancellation, errors during the 
session between buyer and supplier, or a recoverable timeout. In the general data flow of 
figure 2, implicit login may be supported, whereby the broker stores the password for the 
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buyer's organization to be sent to the supplier and uses it upon authentication of the buyer. 
The buyer apphcation may be configured to send a broker both the buyer's userids and 
passwords for gaining access to the RoundTrip software and to the suppUer site. 
Alternatively the broker application can maintain a table of userids and passwords for 
suppliers corresponding to userids and password's provided by the buyer application. At the 
IP session level, it is useful for commxmications among the buyer, broker and supplier 
applications to use a secure socket layer (SSL) protocol so that the data is securely 
exchanged. 

Figure 3 focuses on registration of the supplier 240, buyer 230 and their 
applications. In one embodiment, both the buyer and supplier receive valid market 
participant IDs (MPIDs) from a MarketSite administrator. In overview, the supplier registers 
the set of services it will provide, compatible with the RoundTrip software. For each service 
the supplier provides a URL that points to the service, a URN, and the type of the service. 
The details of the supplier's service registration are described below. The buyer subscribes to 
one or more services that are RoundTrip enabled. The buyer provides URLs for receiving 
session and messages can the error messages. When the buyer is using XCC, this URL may 
be the same as the XCC URL. The buyer provides their supplier assigned account number 
and their organization MPID. The MPID may identify the buyer with any level particularly, 
such as company, department or individual buyer. Localization information also may be 
provided, such as the language, coimtry and currency for transactions. Upon registration, the 
buyer receives a URL to which buyer application can send a broker session start request. The 
details of the buyer's service subscription are described below. Note that a contractual 
relationship between the buyer and supplier may be the basis for receiving a supplier assigned 
account number and corresponding password. A trading partner may fulfill both the rules of 
buyer and supplier in different sessions. 

The table below provides further information regarding supplier service registration, 
according to the RoxmdTrip software embodiment. The information set forth in the table 
enables buyer side applications to connect to and interact with a supplier's RoimdTrip enabled 
services. The information described in the table may be provided either via a paper 
registration form or an online registration- form verified a MarketSite operator. 
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Itcin 


Tle^crintinn 


DocumentExchange 

T^rr*tr»f»rkl Tn form 51 f\ r*n 


Specifies the document exchange protocol and version expected 


DocumentExchange 

Pr^mn Ck f Tn Tirxirtm 51 f 1 on 
r \JLlll<l\,LLll.\JL LllCilLKJll 


Specifies data format expected by the supplier application in the 

oUUlJilCI OCIVIL'C OCo^l\Jll OUul cHlKX OU.JJ|JliCI OCX Vice OCooXLVXl 

End" data messages, e.g., CBL version 2.0. 


DocumentExchange 
Timeout 


Specifies the service timeout value in minutes. 


l^QC UIXLCn LI2/XCndXLgC 

Securitylnfomiation 


w Hi iiicucate ine auiiicniiL/ciiioii dcncm.e imposcQ oy mc iraciing 
partner's service. Options would be implicit or explicit sign-on. 


ServiceURN 


Used as a key to lookup fiirther RoundTrip registry information. 
This is a supplier service specific URN, e.g., "catalog: supplier- 
name". Assigned by the MarketSite operator in agreement with 
the supplier/trading partner. 


ocrviceuivJL 


ine specinc location ^ujkx^j oi me service, r^roviaea oy 
supplier/trading partner. Examples: 
nup.// WWW. supplier. com/ catalog. asp or 
http://www.supplier.com/cgi-bin/catalog.cgi/roundtrip or 
niip,// www.&uppiicr.uoiii/ugi- 
hin/rataloff rpi7FT AVOR=T?nTrNrr)TRTP 

UXXX/(,^CllClXC^.C^l i IT V V_7JV XVVyi^l^Ji-/ X IVlx . 


^**tT7i r*f*Clf*ccion'T'imf* 

out 


O^C^ilXC^ dCXVXL'C o UoCX oCd^Xwli LXXXlCLlUt VdXLiC XXI XXXlXXLXlCo. 


XfJi H i n crP a rtn prTH 

X 1. dUXJ-X^X CU. Lllv/X xu 


THpntifiPQ tViP trJiHiTicr vs^wtn^v thjit rpcri^fPTinO" tViP ^ptvipp THiq 

Xvl^iXLXXl^d LXX^ LXCiUXXl^ L7CiX UX^X I.XXC1.L Xo X^^Xdl^X 1X1^ LXX^ owXVll.'W. X IXXO 

would typically be the MPId (Marketplace Id) of the supplier. 


Serviceld 


The service id unique to a supplier. 


ServiceType 


Specifies the type of service that is being run. 


ServiceName 


Service name. 


AppFieldMap 


Reserved for future use. 


AppServiceData 


Reserved for future use. 



The next table below provides further information regarding initial buyer registration, 
according to the RoundTrip software embodiment. The information described in the table 
may be provided either via a paper registration form or an online registration form verified a 
MarketSite operator. Default values, subject to overrides, can be assigned to many of these 
items, including localization values, the Document Exchange Protocol Information, the 
Accept and Cancel URLs and Labels 



Variable 


Description 


OrgID 


Buyer organization or Buy Site identifier 


BuyerAppName 


Buyer application name/id. 


BuyerApp Version 


Buyer application version. 


BuyerAppFrameSize 


Buyer application's fi*ame size 


DocumentExchangeProtoc 
ollnformation 


Specifies the document exchange protocol and version used. 
For the initial release, the protocol is "RoimdTrip" and the 
version is 1.0. 
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Variable 


Description 


Ses*iionTimeOiit 


Client session timeout value in minutes. 


Language 


The user preferred two-letter ISO language code. Reference 

CBL element LaneCode. 

o . — 


Currency 


Reference CBL element CurrencyCode. 


Countrv 


Can be used to determine/guess the niunber and date 
formats. Reference CBL element CountryCode. 




A T TRT to a buver side ASP/servlet/CGI for unloadine: the 
configured order. 


AcceptLabel 


This is the button label that the trading partner web-based 
services will associate with the Callback URL. Optional. 


CancelURL 


A URL to a buyer side ASP/servlet/CGI for handling the 
user canceling the configurator process. 


CancelLabel 


This is the button label that the suppliers will associate with 
the Cancel URL. 



After initial registration, the buyer will specify the supplier and supplier services that it wants 
to subscribe/unsubscribe to. The following information can be used to identify supplier 
services to which the buyer is subscribing.: 



Variable 


Description 


OrgID 


Buyer organization or BuySite identifier 


SupplierlD 


Identifies the supplier that provides the service being 
registered to. This would typically be the MPId (Marketplace 
Id) of the supplier. 


SupplierServicelD 


The service id unique to this supplier. 



For each service, the buyer will also register and service specific data. Some examples of 
these data items are: 



SupplierAssignedAccoimtN 
um 


For the supplier-based services, this is the customer 
number assigned by the supplier to the buying 
organization. This facilitates contract pricing. 


DistributerAssignedAccount 
Num 


For distributor-based services, this is the customer number 
assigned by the distributor to the buying organization. 
This also facilitates contract pricing. 



Figure 7 and 4 generally illustrate the processes leading to issuance of the broker session 
start document. In figure 7, interactions take place among the user 701, the user's web 
browser 702, a buyer application or BuySite 703, a broker application 704 and the supplier 
application 705. The user navigates to a requisitioning screen with reference to RoundTrip 
software and performs some action 710. The user's action at the requisitioning screen causes 
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an HTTP Post message 71 1 to be sent to the broker application for a broker session start. A 
schema for such a message is set forth below. The broker application verifies the user 
privileges 712 and takes other steps described in more detail below. The broker application 
issues an HTTP reply 713 to the user's web browser 702. 

Figure 4 provides additional detail regarding the broker application's processes in 
response to the buyer's BrokerSessionStart document. The buyer 230 sends a 
BrokerSessionStart document to the broker 210. An HTTP/S Get or Post connection can be 
used. The buyer's document contains the buyer MPID and the buying organization's user ID 
and password. The broker 210 validates the buyer by publishing a ping document to LI 413, 
using the buyer MPID and buying organization's user ID and password. The LI component 
forwards the ping docimient to L2 414 and its ping service 415. The response is a pong 
message which validates the buyer. In an altemative embodiment, the SiteMinder™ product 
by Netegrity'^^ can be used to validate the buyer. Information regarding this product is 
available through http://www.netegritv.coni/products/siteminder.html . Once the buyer is 
validated, the broker returns the list of services to which the buyer has subscribed. When the 
buyer selects one of the returned services, another HTTP/S Get or Post request from the 
browser, to the procurement application, through the broker is generated. In this 
embodiment, the buyer sends the broker a document containing the Supplier-assigned userid 
and password, and SessionID and SessionContext for the buyer session start.. The broker 
receives this request at the start docimient URL. The broker then constructs a Supplier 
Service Session Start XML document, and sends it on as an HTTP/S Post to the supplier. 

A Sox schema for RoundTrip BrokerSessionStart message appears below. Those 
familiar with the art will recognize Sox as an extension to XML proposed as an open 
specification through W3C at HTTP://www. w3.org/TR/NOTE-SOX. The full Sox 
specification, version 2, has been published at 

http://www.commerceone.com/xml/sox/download/index.html. The schema below is self 
documenting. Some comments and explanations of data usage follow the schema. 

<?xml version="1.0"?> 
<!DOCTYPE schema SYSTEM 

"urn:xcomrnerceone:document:corn:cornmerceone:xdk:xml:schema.dtd$1.0"^ 

<schema uri="urn:x-commerceone:document:com:comrnerceone: 
roundtrip:schemas:RoundTripBrokerSessionStart.sox$1.0"> 
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<namespace prefix="cbl" namespace="urn:x- 
commerceone:document:com:corTimerceone:CBL:CBL.sox$1.0"> 

<connment> 

Copyright 1999 Commerce One Inc. 
</comment> 

<elementtype name="BrokerSessionStart"> 
<model> 
<sequence> 

<element type="Loginlnfo7> 
<element type="Sessionlnfo7> 
<element type="PassThruData" occurs="?7> 
</sequence> 
</model> 
</elementtype> 

<elementtype name="Sessionlnfo"> 
<model> 

<element type="SessionContext" occurs="?7> 
</model> 

<attdef name="SessionlD" datatype="string"><required/> 
<explain> 

<p>This is the user session id assigned by the buyer-side 

application. </p> 
</explajn> 
</attdef> 
</elementtype> 

<elementtype name="SessionContext"> 
<model> 

<element type="string" name="Orgld" occurs="?7> // e.g. the BuySite 
internal Buying Organization id. 

<element type="string" name="ParentOrgld" occurs="?7> <!-- e.g. 
the BuySite internal Enterprise (EBO) Id. --> 

<element type="string" name="Orderld" occurs="?7> <!-- Id of user's 
current requisition. — > 

</model> 

</elementtype> 

<elementtype name="Loginlnfo"> 
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<explain> 

<p>The <code>Loginlnfo</code> contains the 
authentication data for signing onto the RoundTrip 
services. </p> 

5 <p>lt is intended that this element be extended to 

support other authentication schemes such as single 
sign-on. </p> 
</explain> 
<model> 
10 <sequence> 

<element type="Organization7> 
</sequence> 
</model> 
</elementtype> 

15 

<elementtype name="Organization"> 

<attdef datatype="string" name="ID"><required/> 
y <explain> 

<p>The <code>Organization</code> may be identified by a 
20 <code>ID</code> that is known to some 

*S <code>Agency</code>. The <code>Agency</code> should be 

identified with an <code>AgencylD</code> (or an 
jU <code>AgencyOther</code>).</p> 
P </explain> 
15 25 </attdef> 

p <attdef name="AgencylD" prefix="cbl" 

^ datatype="AgencyCode"><required/> 

<!-- <explain> 

<p>An <code>Agency</code> chosen from a list of standard 
30 <code>Agencies</code>. This identifies the 

<code>Agency</code> that issued the <code>PartylD</code>. 
For MarketSites, use Other unless the specific MarketSite 
has an AgencyCode.</p> 
</explain> --> 
35 </attdef> 

<attdef datatype="string" name="AgencyOther"> 
<explain> 

<p>lf the <code>AgencylD</code> is <code>Other</code> 
the <code>Agency</code> identifier may be specified 
40 as a string. If the Agency is a MarketSite, use the 

MarketSite short name or MarketSite Participant ID.</p> 
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</explain> 
</attdef> 
</elementtype> 

<elementtype name="PassThruData"> 
<explain> 

<p>A place holder element for any other data that is 
required by the application to process the document(s) and 
other information returned in the BrokerSessionEnd.</p> 
<p><code>Content</code> - Format to be defined by the 
application. Note it cannot be in XML format (XML data can 

be URL encoded or otherwise encoded). </p> 

</explain>. 
<model> 

<element name="Content" type="string" occurs="?7> 
</model> 
</elementtype> 
</schema> 

This schema works in conjunction with XML Common Business Language (xCBL) 
documents published as an open standard at the Commerce One download site referenced 
above. In other embodiments of the present invention, EBXML documents (Sxm sponsored) 
or other schemas could be used for starting the broker session. The table below explains 
some data usage corresponding to the schema above. 



Variable 


Description 


SessionID 


Identifies the user session. 


SessionContext 


Session context. For example, this may include 
the user's requisition id and buyer organization Id. 


UserlD 


The user id and password field will be activated 
when single sign-on is enabled. 


Password 




OrgID 


This will be the organization's MarketSite 
Participant ID (MPID) when the OrglDAgency is 
set to a MarketSite. Alternatively, ttiis could an 
identifier assigned by another agency such as 
EAN. 


OrglDAgency 


This will be the identifier for the agency that 
assigned the OrgID. For example, MarketSite.net 
or EAN. 


PassThruData 


A self-describing data structure thiat is passed 
through by the service broker. This can be used by 
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Variable 


Description 




the buyer and supplier applications to exchange 
service specific data without needing a protocol 
change. 



Figure 7 provides an additional view of this interaction. In practice of the RoundTrip 
embodiment, the broker 703, at the service list selection URL receives the buyer's request for 
a list of available services 721 . Upon receiving this request, the broker consults its database 
to determine the set of services to which the buyer with the given OrgID is subscribed 722. It 
saves the user session context for later use 723. It returns this list of services to the buyer's 
browser, as an HTTP/S Reply 724. The buyer selects a service from the list of services 730 . 
This causes the browser to send an HTTP/Get or Post request 730 to the procurement 
application, which in tum does an HTTP/S Post 73 1 to the RoundTrip broker, to send to it, 
over an HTTP/S connection, the service selected, along with the supplier assigned 
userid/password. The broker looks up the URL of the selected service 732, gathers context 
data for use in the supplier session 733 and creates data structures to support the supplier 
session 734. In particular, in the RoimdTrip embodiment, the broker creates the Service 
Session Start request document 734, and forwards it 735 over an HTTP/S connection, to the 
supplier 705. The supplier caches the data, performs a redirect, and then sends an HTTP/S 
Reply to the broker 737, who forwards the reply 738 on to the buyer 702. The broker 703 
can log the session 739. 

Figures 7 and 5 portray processes including supplier service selection and supplier 
service session start. The buyer 230 transmits the service selection to the broker application 
or e-commerce hub 210. The broker processes the selection and generates a supplier service 
session start document which it transmits to the supplier 240. 

When the user selects a specific service URL, the Service Broker sends a "Supplier 
Service Session Start" request to the chosen service's supplier application. The service 
context data is delivered to the supplier application via an HTTP Post to the URL 
(ServiceURL) specified by the supplier during registration. This is the initial communication 
between the broker application and the service application. In the RoimdTrip embodiment, 
data is delivered as an XML format document within a hidden form field. The name of the 
hidden field typically is the name of the root element tag in the document being sent - for 
example, RTServiceStart, RTServiceEnd, RTServiceCancel, and RTServiceError. The 
general form for conveying the hidden field can use the following syntax: 
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<FORM ... 

< hidden name="RTServiceStart" value ="<XML document 



In greater detail, the following schema depicts one embodiment of a supplier service 
session start document. Both the specific schema and some conimon schema information 
used in conjunction with the specific schema are provided. 

10 <?xml version="1 .0"?> 

<!DOCTYPE schema SYSTEM 

"urn:xcommerceone:docunnent:conn:commerceone:xdk:xnril:schema.dtd$1.0"> 
<schema uri="urn:x- 

connmerceone:docunnent:com:conrinrierceone:roundtrip:schenrias:RoundTripServ 
*2i5 iceStart.sox$1.0"> 
!y <comment> 

iJ Copyright 1999 Commerce One Inc. 

^3 </comment> 

m 

kQio <namespace prefix="cbl" namespace="urn:x-commerceone:document:com: 

V commerceone:CBL:CBL.sox$1.07> 

i'tJ 

P <namespace prefix-'common" namespace="urn:x-commerceone:document: 

jri com:commerceone:roundtrip:RoundTripCommonTypes.sox$1.07> 

O25 

'3 <elementtype name="RTServiceStart"> 

<model> 

<sequence> 

<element prefix="common" 
30 type="DocumentExchangeProtocollnformation7> 

<element prefix="common" type="Sessionlnfo7> 

<element type="Loginlnfo7> 

<element name-TimeOut" type="int" occurs="?7> 

<element prefix="cbl" name="Language" type="LangCode" occurs="?7> 

35 <element prefix="cbl" name="Currency" type="CurrencyCode" occurs="?"/> 

<element prefix="cbl" name="Country" type="CountryCode" occurs="?"/> 

<element name="BuyerApplnfo" prefix-'common" type="Applicationlnfo" 
occurs="?7> 

<element prefix-'common" type="AcceptlnfoType7> 
40 <element prefix="common" type="CancellnfoType7> 
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<element prefix="common" type="URLDataType" name="ErrorURL" 
occurs="?7> 

<element prefix="connmon" type="PassThruData" occurs="?7> 
<element name="SupplierPartNum" type="LimitedString" 
occurs="?7> 

<eleinent name="SupplierlD" type="LimitedString" occurs="?7> 
<element name="SupplierlDAgency" type="LimitedString" 

occurs="?7> 

<element name="SupplierAssignedAccountNum" 

type="LimitedString" occurs="?7> 

</sequence> 
</model> 
</elementtype> 

<elementtype name="Loginlnfo"> 
<explain> 

<p>The <code>Loginlnfo</code> contains the 
authentication data for signing onto the RoundTrip 
services. </p> 
</explain> 
<model> 
<sequence> 

<element name="UserlD" type="LimitedString" occurs="?7> 
<element nanne="Password" type="LimitedString" occurs="?7> 
<element name="OrglD" type="LimitedString7> 
<element name="OrglDAgency" type="LimitedString" occurs="?7> 
</sequence> 
</model> 
</elenrienttype> 

</schema> 

Common Types 

<?xml version="1 .0"?> 

<!DOCTYPE schema SYSTEM "urn:x-connmerceone:document:conn: 
connnierceone:xdk:xml:schenna.dtd$1 .0"> 

<schema uri="urn:x-commerceone:document:conn:connmerceone: 
roundtrip:schemas:RoundTripCommonTypes.sox$1.0"> 

<comment> Copyright 1999 Commerce One Inc. </comment> 
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<comment> Accetplnfo and Cancellnfo should use a common datatype which 
could be Actionlnfo 

</comment> 

<elementtype name="AcceptlnfoType"> 
<model> 
<sequence> 

<element type="NameDataType" name="LaberV> 
<element type="URLDataType" name="URL" /> 
</sequence> 
</model> 
</elementtype> 

<elementtype name="CancellnfoType"> 
<model> 
<sequence> 

<element type="NameDataType" name="LaberV> 
<element type="URLDataType" name="URL" /> 
</sequence> 
</model> 
</elementtype> 

<elementtype name="ScreenSize"> 
<model> 

<element name="HorizontalSize" type="int7> 

<element name="VerticalSize" type="int7> 
</model> 
</elementtype> 

<elementtype name="Sessionlnfo"> 
<modeI> 

<element type="SessionContext" type="string" occurs="?7> 
</model> 

<attdef name="SessionlD" datatype="UUID"> 
<required/> 

<explain> 

<p>This is the service session id assigned by the broker. </p> 
</explain> 

</attdef> 
</elementtype> 
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<elementtype name="PassThruData"> 
<explain> 

<p>A place holder element for any other data that is 
required by the application to process the document(s) and 
other information returned in the BrokerSessionEnd.</p> 
<p><code>Content</code> - Format to be defined by the 
application. Note it cannot be in XML format (XML data can 
be URL encoded or otherwise encoded). </p> 
</explain> 

<model> 

<element name="Blob" type="string7> 
</model> 
</elementtype> 

<elementtype name="DocumentExchangeProtocollnformation"> 
<empty/> 

<attdef name="Protocol" datatype="LimitedString"> 

<default>RoundTrip</default> 
</attdef> 

<attdef name="ProtocolVersion" datatype="LimitedString"> 

<default>1 .0</default> 
</attdef> 
</elementtype> 

<elementtype name="Name"> 
<model> 

<element name="NameString" type="NameDataType7> 
</model> 
</elementtype> 

<datatype name="NameDataTyjDe"> 

<varchar maxlength="50" datatype="string7> 
</datatype> 

<datatype name="LimitedString"> 

<varchar maxlength="80" datatype="string7> 
</datatype> 

<elementtype name="Applicationlnfo"> 
<model> 
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<element nanne="AppFrameSize" type="ScreenSize" occurs="?7> 
</model> 

<attdef nanne="AppName" datatype="string"> 

<required/> 
</attdef> 

<attdef name="AppVersion" datatype="string"> 

<required/> 
</attdef> 
</elementtype> 

<datatype name="UUID"> 

<varchar maxlength="64" datatype="string"/> 
</datatype> 

<datatype name="URLDataType"> 

<varchar maxlength="256" datatype-'string" /> 
</datatype> 

<datatype name="URNDataType"> 

<varchar maxlength="256" datatype="string7> 
</datatype> 

</schema> 

The following table explains some of the data items included in the supplier service 
session start XML document. In this table, the Supplier Service Session Start data is 
categorized. Session data is MarketSite Service Broker session information. Data such as 
session id is used by the broker application to associate the acquired data (order details) with 
a supplier service session. Other data, such as language, is provided as a courtesy so that the 
web-based service can provided a tailored experience. Authentication data includes 
information such as the organization's user-id and password. Authorization data, for catalogs 
and configurators, for instance, includes the buyer's supplier assigned accoimt nimiber or 
customer nxmiber. Parameter data provides information required by the supplier's service 
application. For example, a configurator will need a supplier part number. Parameter data 
typically can be provided by the buyer application. Finally, action data includes button labels 
and URLs for accept, cancel and other actions. 
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Variable 


Category 


Description 


DocumentExchange 

"Prof f* r*l Tti •FfM'in 51 ti ori 


Session 


Specifies the document exchange protocol and 
version is 1.0. 






THiQ rlif^nt QpQsion iH rTTTTTT^^ allows tHf* 

Roimdtrip broker to associate the incoming 

p on fi oil rati on data Tvia Af*rpnt TTRT.^ with the 

suppUer service and the buyer that performed 
the action 


TimeOut 


Session 


Client session timeout value in minutes is 
optional. 


T nticnifiCTR 




TTip iispr nrpfpTTpH two-lf*ttpr TSIO lanpiiap"f; 
code Reference CBL element LanffCode ■ 




Session 


Reference CRL element CurrencvCode is 
Optional. 


Country 


Session 


Can be used to determine/guess the nxmiber 
and date formats. Reference CBL element 
CoimtryCode. 


BuyerAppName 


Session 


Buyer application name/id. 


BuyerApp Version 


Session 


Buyer application version. 


BuverAnnFrameSize 


Session 


Buyer application's frame size. 






T TqpH "for imnlif*it locrin Tfiis mpans tfiat tViP 

KJ J\J\J- LkjL XIXXIJXIVXI l^J^XXX. X XXXo XXXv/CXXXO LXXCXL LXX^ 

userid is on a ner buvine; organization 
registered service basis. 


Password 


Authentication 


Used for implicit login. This means that the 
password is on a per buying organization 
registered service basis. 


OrgID 


Authentication 




OrgID Agency 


Authentication 




AcceptURL 


Action 


A URL to a MarketSite ASP/servlet/CGI for 

TiT*r*ppQQino" tVif* crinficnTTpH ot*Hf*T 

LIX UL/WdOXlX^ IXX& ^V^XXXX^LXX^U UXU^X . 


AcceptLabel 


Action 


This is the button label that the trading partner 

\vf*V>-V*aspH Qf^rvipf^s will assof*iatp vvitVi tVip 

W^L/ t/do&U- dWX VX^WO WXXX CXOOW^XCXX^ WXLXX LXX^ 

Accept URL. 


CancelURL 


A ct\ on 


A URL to a MarketSite ASP/servlet/CGI for 

xm. * ■* ' ^ ' ' CX XTX.CU. XVwLk_7X Lw jrM.t>JM^ / OwX VXWw^^XaJX xv/x 

handling the user canceling the configurator 
process. 


CancelLabel 


Action 


This is the button label that the suppliers will 
associate with the Cancel URL. 


ErrorURL 


Action 


A URL to a MarketSite servlet for displaying 
errors. 


PassThruData 


Parameter 


This parameter is passed through by the 
service broker. This can be used by the buyer 
and supplier applications to exchange service 
specific data that are not accounted for in the 
protocol. This would enable such buyers and 
suppliers to inte^ate without having to wait 
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Variable 


Category 


Description 






for a protocol change. 



The previous table shows a basic supplier service session start data layout. The following 
table shows a list of additional supplier specific data items that can be part of the RoimdTrip 
Supplier Service Start document: 



Variable 


Category 


Description 


SupplierPartNum 


Parameter 


Used by web-based configurators. 


SupplierlD 


Parameter 


While not required if connecting directly 
to a supplier, probably usefiil if 
connecting an intermediate trading 
partner. 


SupplierlDAgency 


Parameter 


Used to identify the agency that created 
any identifiers (e.g. Supplier ID and 
Supplier Account Number) in this 
information set. 


SupplierAssignedAccount 
Num 


Parameter 


For the supplier-based services, this is the 
customer number assigned by the supplier 
to the buying organization. This 
facilitates contract pricing. 



The following example provides a docimient consistent with the schema above. 



<?xml version="1 .0"?> 

<?soxtype urn:x-comrnerceone:docurnent:com:commerceone:roundtrip:schemas: 
RoundTripServiceStart.sox$1 .0?> 
<RTServiceStart . 

xmlns:common="urn:x- 
commercone:document:com:comiTierceone:roundtrip:schemas: 
RoundTripCommonTypes.sox$1 .0" 

xmlns:cbl="urn:x-cornmerceone:document:com:corTimerceone: 
CBL:CBL.sox$1.0"> 
<common:DocumentExchangeProtocollnformation Protocol-'RoundTrip" 
ProtocolVersion="1 .07> 

<common:Sessionlnfo SessionlD="CF543873-D7B9-1 1D3-830B- 
00609709DDA17> 
<Loginlnfo> 

<UserlD>123456</UserlD> 
<Password>my password</Password> 

<OrglD>buyer organization id</OrglD> 

<OrglDAgency>MarketSite.net</OrglDAgency> 
</Loginlnfo> 

<TimeOut>1 0</TinneOut> 
<Language>en</Language> 
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<Currency>USD</Currency> 
<Country>US</Country> 

<BuyerApplnfo AppName="BuySite" AppVersion="6.0"> 
<common:AppFrameSize> 
<common:ScreenSize> 

<common:HorizontalSize>600</common:HorizontalSize> 
<coiTirnon:VerticalSize>800</common:VerticalSize> 
</common:ScreenSize> 
</common:AppFranneSize> 
</BuyerApplnfo> 
<common:AcceptlnfoType> 
<common:Label>Order</common:Label> 
<common:URL>http://www.marketsite.net/servlet/end</comm 
</common:AcceptlnfoType> 
<common:CancellnfoType> 
<common:Label>Cancel</common:Label> 
<common:URL>http://\AnAAA/.marketsite.net/sei^let/cancel<^ 
</common:CancellhfoType> 

<ErrorURL>http://www.marketsite.net/sei^let/errhandler</Error^ 
<SupplierAssignedAccountNum>4356</SupplierAssignedAccountNum> 
</RTServiceStart> 

Figure 2 depicts the supplier service session and direct buyer to supplier interaction 
250. The buyer and supplier communicate directly with each other, without need for broker 
involvement, monitoring or logging, hi other embodiments, the broker can forward many or 
all of the messages between the buyer and supplier, thereby enabling the broker application to 
log all or some aspects of the interaction to facilitate error recovery. 

When the buyer is done with the supplier site, he may select a Submit or Cancel button in 
the browser. These selections lead to generation of a Service Session End or Service Session 
Cancel XML document, respectively, which is to be sent to the buyer by the supplier via the 
broker, as a hidden form field, over HTTP/S Post. The supplier service posts to a URL 
(CallBackURL) specified in the Supplier Service Session Start data. The data in this the 
posted document include Supplier Service Session End data as an XML docimient within a 
hidden form field, consistent with the following schema. The supplier's document also 
includes an order response (e.g., a shopping cart) as a CBL format document within a hidden 
form field. A schema for and example of a shopping cart response follow. The Service 
Session End document is sent to a buyer provided Submit URL. Altematively, a Service 
Session Cancel document is sent to a buyer provided Cancel URL. The buyer receives and 
processes these documents. 
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Any errors that occur during this interaction may be posted to a specified error URL. 
These errors can be automatically displayed within the buyer's browser. 

The supplier service session end document is an HTTP form is posted to the broker 
callback URL when the Supplier Service Session Ends. This form contains the "Supplier 
Service Session End" XML document and a List of Order Details CBL documents in hidden 
fields. The following syntax is used: 



<FORM ACTION="http://roundtrip.marketsite.net/servlet/end" 
METHOD="POST" 
NAME="CallBackDia!og"> 
<INPUT TYPE="HIDDEN" NAME="RTServiceEncl" 
VALUE="<?xml version="1.0"?> 

this is an HTML encoded RTServiceEnd document 
"> 

</FORM> 

The following schema depicts a supplier service session end document. 

<?xml version="1 .0"?> 

<!DOCTYPE schema SYSTEM "urn:x- 

commerceone:document:com:commerceone:xdk:xml:schema.dtd$1.0"> 
<schema uri="urn:x- 

commerceone:document:roundtrip:schemas:RoundTripServiceEnd.sox$1.0"> 
<comment> 

Copyright 1999 Commerce One Inc. 
</comment> 

<namespace prefix="cbl" namespace="urn:x- 
commerceone:document:com:commerceone:CBL:CBL.sox$1.07> 

<namespace prefix="common" namespace="urn:x- 

commerceone:document:com:commerceone:roundtrip:RoundTripCommonT 
ypes.sox$1.07> 

<elementtype name="RTServiceEnd"> 

<model> 

<sequence> 

<element prefix="common" 
type="DocumentExchangeProtocollnformation7> 

<element prefix="common" type="Sessionlnfo7> 
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<element prefix="cbl" name="Language" type="LangCode" occurs="?7> 
<element prefix="cbr name="Currency" type="CurrencyCode" 
occurs="?"/> 

<element prefix="cbr name="Country" type="CountryCode" occurs="?7> 
<elennent type="ResponseData7> 

<element prefix="common" type="PassThruData" occurs="?7> 
<element name="RequestEcho" type="RTServiceStart" occurs="?7> 
</sequence> 
</nnodel> 
</elementtype> 

<elennenttype name="ResponseData"> 
<empty/> 

<attdef name="ResponseDataType" datatype="LimitedString"> 

<required/> 
</attdef> 

<attdef name="ResponseDataFormat" datatype="LimitedString7> 

<required/> 
</attdef> 

<attdef nanne="ResponseDataFornnatVersion" datatype="LimitedString7> 

<required/> 
</attdef> 
</elementtype> 

<elementtype name="ShoppingCart"> 
<explain> 

<p>A <code>ShoppingCart</code> is typically returned from a 
RoundTrip session with a supplier's catalog or configurator. 
The <code>ShoppingCart</code> will contain an <code> 
OrderReq uest</cod e> . </p> 

<p><code>OrderRequest</code> - an order request containing the 
items selected by and/or configured by the user from the supplier's 
web based catalog/configurator. </p> 
</explain> 

<extends type="ResponseData"> 
<append> 

<element name="CartlD" type="LimitedString7> 
<element prefix="cbl" type="OrderRequest"/> 
</append> 
</extends> 
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</elementtype> 
</schema> 

-\ 

In this schema, the ResponseData element enables polymorphism of the session end data 
document. The extension of ResponseData is self-describing. That is, the basic attributes of 
ResponseData, which may be extended and adapted in various embodiments, describe the 
extended data attributes. Data type and version attributes allow the buyer application to 
determine what data is associated with the message. An optional data format attribute 
permits further definition of the data associated with the message. This is an extension of 
XML. The same message, v/ith variants, can be adapted to a variety of functions, such as 
conveying reference to or the values of shopping cart data, conveying product configuration 
data, conveying tax calculation data or conveying shipping or foreign freight forwarding data. 
Use of a poljmiorphic data schema decouples programming from the evolution of docxmient 
types and applications. Use of namespaces supports coordination of docimient type names, 
development, deployment and maintenance of applications. Relative to a namespace, a 
schema identifier is provided with a message, which is resolvable in a context of a system 
identifier. In the sample schemas herein, the system identifier is explicit and part of the self- 
describing data. The system identifier may be universally unique, across the namespace of 
the Intemet, or locally imique in some narrower domain. At some sacrifice of general 
adaptability, the system identifier may be implicit in the data tables or program code used by 
the buyer or supplier application or it may be implicit in the choice of a narrower domain 
than the Intemet. Other Sox extensions of XML which are useful in practicing aspects of the 
present invention are support of typed data, a predefined set of intrinsic types, such as string, 
int, URJ, and date, user defined types based on enumerated, scalar, and varchar type 
definitions, namespaces and versions for schemas, and an extensibility mechanism that 
facilitates the reuse and evolution of schemas and element types. Translation of Sox to Java 
data formats can leverage strong typing and data structures which are readily mapped into 
Java. 

Polymorphism is not limited in this invention to responses from a supplier. Responses 
fi-om a buyer to a supplier also can take advantage of this method and data structure. 
Altematively, poljmiorphism can be used at the outset of a session, in a first message (not 
necessarily the actual first message) from the initiating party to the broker. Either the buyer 
or supplier can initiate a session through the broker and use polymorphism during the 
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initiating. For example, a buyer can initiate a status inquiry or a purchase order start using 
data structures equivalent to ResponseData, in place of PassThroughData. A supplier can 
initiate a session, reversing the roles of the schemas or messages offered as examples herein, 
and use polymorphism during the initiating. This may be useful to a supplier for purchase 
order responses, invoices or advance shipment notices. At the conclusion of a session 
initiated by a supplier, the buyer may respond with data regarding changed conditions. 
Alternate schedules or other delivery information can be provided. Altemate configurations 
can be provided if a selected configuration has become unavailable. 

The following table explains some data items that are part of the Supplier Service 
Session End document: 



Variable 


Category 


Description 


DocimientExchangeProtoc 
ollnformation 


Session 


Specifies the document exchange 
protocol and version used, e.g., 
"RoimdTrip" and the version is 1 .0. 


SessionID 


Session 


Same as the Session ID provided as 
part of the Session Start. 


j-rdnguage 




LJk>dui 11 mc rc&uii udui coiiuiiiia <x 

specified language code and the 
lanenae'e text in the result data is 
different than "Language" specified 
in the RoundTrip context. The user 
preferred two-letter ISO language 
code. 


Currency 


Session 


Useful if the result data contains a 
monetary amount without a specified 
currency code and the currency in 
the result data is different than 
"Currency" specified in the 
RoundTrip context. 


Country 


Session 


Useful if the result data contains any 
country specific formatted data 
without a specified coimtry code and 
the country specific formatted data 
in the result data is different than 
"Coimtry" specified in the 
RoundTrip context. Reference CBL 
element CountryCode. 


ResponseDataFormat 


Response 


The Session End data format 


ResponseDataFormatVers 
ion 


Response 


Version number of response data 
format, e.g., CBL 2.0. 


ResponseData 


Response 


Polymorphic data element, 
supporting shopping cart and other 
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Variable 


Category 


Description 






functions. 


ResponseDataType 


Response 


Specifies the type of Response Data. 


PassThruData 




Used by the buyer and supplier 

specific data that are not accounted 
for in the protocol. This would 
enable such buyers and suppliers to 
integrate without having to wait for a 
protocol change. 




Parameter 


Echo back of original request. 
Provided for sanity checking - if the 
broker wants to process the Service 
End document according to data in 
the Service Start Request, for 
example. 



. p; As an extension of ResponseData, the following schema supports a shopping cart. 

*y ■ 

5 <?xml version="1.0"?> 

£ <!DOCTYPE schema SYSTEM "urn:x-commerceone:document:conn: 

.fe commerceone:xdk:xml:schema.dtd$1 .0"> 

{1 

1^ <schema uri="urn:x-commerceone:document:com: 

ify commerceone:CBL:CBL.sox$1 .0"> 

Q 

IJ1 <intro> 

□ <h1>Order Request</h1> 

15 <p>Copyright Notice</p> 

<p>Common Business Library 2.0<br/> 
Copyright 1999 Commerce One, lnc.</p> 

<p>Permission is granted to use, copy, modify and distribute the 
DTD's, schemas and modules in the Commerce One Common Business 
20 Library Version 2.0 subject to the terms and conditions specified 

at <tt>http://www.marketsite.net/xml/cbl/copyright.html</tt></p> 
</intro> 

<elementtype name="OrderRequest"> 
25 <model> 

<sequence> 

<element type="OrderRequestHeader7> 
<element type="ListOfOrderRequestDetairV> 
<element type="OrderRequestSummary7> 
30 </sequence> 
</model> 
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</elementtype> 

</schema> 

5 <?xnnl version="1 .0"?> 

<!DOCTYPE schema SYSTEM "urn:x-commerceone:document:com: 
commerceone:xdk:xml:schema.dtd$1.0"> 

<schema uri="urn:x-commerceone:document:com: 
10 commerceone:CBL:CBL.sox$1.0"> 

<intro> 

<h1>Order Request Detail</h1> 



15 <p>Copyright Notice</p> 

<p>Common Business Library 2,0<br/> 
Copyright 1999 Commerce One, lnc.</p> 
p <p>Permission is granted to use, copy, modify and distribute the 

^0 DTD's, schemas and modules in the Commerce One Common Business 

20 Library Version 2.0 subject to the terms and conditions specified 

W at <tt>http://\A^ww.marketsite.net/xml/cbl/copyright.html</tt></p> 



</intro> 

<elementtype name="OrderRequestDetail"> 



^- 25 <model> 

1^ <extends type="BaseltemDetail"> 

m <append> 

□ <sequence> 

iH <element type="SupplierConfigNum" occurs="?"/> 

□ 30 <element type="string" name="GeneralNote" occurs="?7> 
O <element type="Tax" occurs="?"/> 

<element type="ListOfAllowOrCharge" occurs="?"/> 
<element type="Price" name="BuyerExpectedUnitPrice"/> 
<element type="ListOfAttachment" name="OrderDetailAttachment" 



35 occurs="?7> 

<element type="boolean" name="lmmutable" occurs="?7> 
</sequence> 
</append> 
</extends> 
40 </model> 

</elementtype> 

<elementtype name="ListOfOrderRequestDetail"> 
<model> 

45 <element type="OrderRequestDetair' occurs="+7> 

</model> 
</elementtype> 

</schema> 
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<?xml version="1.0"?> 

<!DOCTYPE schema SYSTEM "urn:x-commerceone:document:com: 
commerceone:xdk:xml:schema.dtcl$1.0"> 

<schema uri="urn:x-commerceone:document:com: 
commerceone:CBL:CBL,sox$1 .0"> 

<intro> 

<h1>Order Request Header</h1> 

<p>Copyright Notice</p> 
<p>Comnnon Business Library 2.0<br/> 
Copyright 1999 Commerce One, lnc.</p> 
<p>Permission is granted to use, copy, modify and distribute the 
DTD's, schemas and modules in the Commerce One Common Business 
Library Version 2.0 subject to the terms and conditions specified 
at <tt>http://\A/ww.marketsite.net/xml/cbl/copyright.html</tt></p> 
</intro> 

<elementtype name="OrderRequestHeader"> 
<model> 

<sequence> 

<element type="datetime" name="OrderRequestDate7> 
<element type="OrderRequestReference7> 
<element type="OrderParty" occurs="?7> 
<element type="Tax" occurs="?7> 

<element type="CurrencyCode" name="OrderCurrency7> 
<element type="LangCode" name="OrderLanguage7> 
<element type="string" name="GeneralNote" occurs="?7> 
<element type="boolean" name="lmmutable" occurs="?7> 
<element type="ListOfAttachment" 
name="OrderRequestHeaderAttachmeht" occurs="?7> 
</sequence> 
</model> 
</elementtype> 

</schema> 

<?xml version="1 .0"?> 

<!DOCTYPE schema SYSTEM "urn:x-commerceone:document:com: 
commerceone:xdk:xml:schema.dtd$1 .0"> 

<schema uri="urn:x-commerceone:documeht:com: 
commerceone:CBL:CBLsox$1 .0"> 

<intro> 

<h1>Order Request Reference</h1> 
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<p>Copyright Notice</p> 
<p>Comnnon Business Library 2.0<br/> 
Copyright 1999 Commerce One, lnc.</p> 
5 <p>Permission is granted to use. copy, modify and distribute the 

DTD's, schemas and modules in the Commerce One Common Business 
Library Version 2,0 subject to the terms and conditions specified 
at <tt>http://NAnAAA^.marketsite.net/xml/cbl/copyright.html</tt></p> 

10 <p>A collection of references that are used by 

<code>OrderRequest</code>. 
</intro> 

<elementtype name="OrderRequestReference"> 
15 <explain> 

<p><code>AccountCode</code> is the agreement number between a 
buyer and a supplier. An account may contain several contracts 
in it.</p> 

<p><code>CustRefNum</code> is the Order Request identification 
'^po number.</p> 

(x| <p><code>BuyerRefNum</code> is Buyer's Purchase Order Num.</p> 

<p><code>SupplierRefNum</code> is Supplier's Order Num.</code> 
or Suppliers Sales Order Num.</p> 

<p><code>SupplierConfigNum</code> is a configuration number. </p> 
'^'25 <p><code>ListOfReferenceCoded</code> - This is used for other 

references that a buyer want to provide to supplier, such as 
Buyer Catalog Reference Number. </p> 



m 



ill 



p </explain> 
\fl <model> 
□ 30 <sequence> 

p <element type=" Reference" name="AccountCode" occurs="?7> 

<element type="Reference" name-'CustRefNum" occurs="?7> 
<element type="Reference" name="BuyerRefNum" occurs="?7> 
<element type=" Reference" name="SupplierRefNum" occurs="?"/> 
35 <element type="Reference" name="SupplierConfigNum" occurs="?"/> 

<element type="ListOfReferenceCoded" occurs="?"/> 
</sequence> 
</model> 
</elementtype> 



40 



</schema> 



<?xml version="1.0"?> 

<IDOCTYPE schema SYSTEM "urn:x-commerceone:document:com: 
45 commerceone:xdk:xml:schema,dtd$1 .0"> 

<schema uri="urn:x-commerceone:document:com: 
commerceone;CBL:CBL.sox$1 .0"> 
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<intro> 

<h1>Order Request Summary</h1> 

<p>Copyright Notice</p> 
<p>Common Business Library 2.0<br/> 
Copyright 1999 Commerce One, lnc.</p> 

<p>Permission is granted to use, copy, modify and distribute the 
DTD's, schemas and modules in the Commerce One Common Business 
Library Version 2.0 subject to the terms and conditions specified 
at <tt>http://w\AW,marketsite.net/xml/cbl/copyright.html</tt></p> 
</intro> 

<elementtype name="OrderRequestSummary"> 
<modei> 

<sequence> 

<element type="Decimal18_3" name="TotalAmount7> 
<element type="int" name="TotalLineNum" occurs="?7> 
</sequence> 
</model> 
</elementtype> 

</schema> 

An example of an end document extended by a shopping cart morphism 
follows: 

<?xml version="1.0"?> 
<?soxtype urnix- 

commerceone:document:com:commerceone:roundtrip:schemas:RoundTripServic 

eEnd.sox$1.0?> 

<RTServiceEnd 

xmlns:common="urn:x- 
commercone:document:com:commerceone:roundtrip:schemas:RoundTripCommo 
nTypes.sox$1.0", 

xmlns:cbl="urn:x- 
commerceone:document:com:commerceone:CBL:CBL.sox$1.0"> 
<common:DocumentExchangeProtocol Information Protocol="RoundTrip" 
Protocol Version="1 .07> 

<common:Sessionlnfo SessionlD="CF543873-D7B9-1 1 D3-830B- 
00609709DDA17> 

<Language>en</Language> 
<Currency>USD</Currency> 
<Country>US</Country> 
<ShoppingCart ResponseDataFormat="CBL" 
ResponseDataFormatVersion="2.0" ResponseDataType="OrderRequest"> 
<CartlD>3456</CartlD> 
<OrderRequest xmlns="urn:x-commerceone:document:com:commerceone: 
CBL:CBL.sox$1.0"> 

<OrderRequestHeader> 
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<OrderRequestDate>1 9990531 T19;55:00</OrderRequestDate> 
<OrclerRequestReference> 

<AccountCode><Reference><RefNum>CTOP</RefNum></Referenc 
e> </AccountCode> 

<BuyerRefNum><Reference><RefNum>100</RefNum></Reference 
> 

</BuyerRefNum> 

<SupplierRefNum><Reference><RefNum>2</RefNum></Reference> 
</SupplierRefNum> 

</OrderRequestReference> 
<OrderParty> 

<BuyerParty><Party> 
<NameAddress> 

<Name1>Mr. Muljadi Sulistio</Name1> 

<Name2>Attention:Business Service Division</Name2> 

<Address1>1600 Riviera Ave.</Address1> 

<Address2>Suite #200</Address2> 

<City>Walnut Creek</City> 

<State>CA</State> 

<PostalCode>94596</PostalCode> 

<Country>US</Country> 

</NameAddress> 

<OrderContact> 

<Contact> 

<ContactName>Mr. Muljadi Sulistio</ContactName> 
<Telephone>(650) 932-4555</Telephone> 
<Email>mike.holloway@commerceone.com</Email> 
<Fax>(650) 468-8900</Fax> 

</Contact> 

</OrderContact> 
<ReceivingContact> 

<Contact> 

<ContactName>Mr. Debbie Dub</ContactNanne> 
<Telephone>(650) 932-4555</Telephone> 
<Email>debbie.dub@connmerceone.com</Email> 
<Fax>(650) 468-8900</Fax> 

</Contact> 

</ReceivingContact> 
<ShippingContact> 

<Contact> 

<ContactNanne>Mr.John Wayne</GontactName> 
<Telephone>(650) 932-4555</T elephone> 
<Email>john.wayne@commerceone.com</Email> 
<Fax>(650) 468-8900</Fax> 

</Contact> 

</ShippingContact> 

</Party></BuyerParty> 

<SupplierParty><Party> 
<NameAddress> 
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<Name1 >Millenium Supplier</Name1 > 
<Name2>Attention: Office Supply Division</Name2> 
<Address1>1600 Riviera Ave.</Address1> 
<Address2>Suite #200</Address2> 
<City>Walnut Creek</City> 
<State>CA</State> 
<PostalCode>94596</PostalCode> 
<Country>US</Country> 
</NameAddress> 
. </Party></SupplierParty> 
</OrderParty> 

<OrderCurrency>USD</OrderCurrency> 
<OrderLanguage>EN</OrderLanguage> 
</OrderRequestHeader> 
<ListOfOrderRequestDetail> 
<OrderRequestDetail> 

<LineltemNum>1 </LineltemNum> 

<SupplierPartNum> 

<PartNum> 

<Agency>AssignedBySupplier</Agency> 

<PartlD>12345</PartlD> 

</PartNum> 

</SupplierPartNum> 

<[temDescription>Sanford Highlighting 
Marker</ltennDescription> 

<Quantity> 
<Qty>000000000001 .000</Qty> 
< U n i tOf M eas u re> E A</U n itOf Measu re> 
</Quantity> 

<Transport Direction="SupplierToBuyer"> 
<Mode>Air</Mode> 
<Mean>Express</Mean> 
<Carrier>Fedex</Carrier> 
<CustShippingContractNum>CTOP123</CustShippingContractNum> 
<Shippinglnstruction>Please handle with care 
</Shippinglnstruction> 
</Transport> 

<OffCatalogFlag>false</OffCatalogFlag> 

<BuyerExpectedUnitPrice> 
<Price><UnitPrice>00000000010.0000</UnitPrice></Price> 
</B uyerExpected U n itPrice> 
</OrderRequestDetail> 
</ListOfOrderRequestDetail> 
<OrderRequestSummary> 

<TotalAmount>000000000001000.000</TotalAmount> 
<TotalLineNum>1 </TotalLineNunn> 
</OrderRequestSumnnary> 
</OrderRequest> 
</ShoppingCart> 
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</RTServiceEnd> 

Figure 6 depicts a sequence ending the broker session, upon completion of the suppHer 
service session. Once the buyer 230A is done, an order or cancel button is selected at the 
buyer browser. This generates an HTTP/S Post of a service session end docxunent to the 
broker application. The broker sends it through the LI component 413 to a forwarding 
component of the L2 component 416. The forwarding component processes the data, 
receives a service session end document from the supplier application, forwards the 
docxmient to the buyer's procurement application 230B, receives a reply, arid forwards the 
reply to tile buyer for display in the buyer's browser or other viewing software 23 OA. In the 
context of the present invention, the buyer application can refer to the buyer's browser, the 
procurement application or both. When the service interaction completes and the supplier 
sends a "Supplier Service Session End" request to the broker, the broker processes the 
"Supplier Service Session End" message and generates an HTTP post to the buyer callback 
URL that was specified by the buyer during registration. The data in this communication 
contains the supplier service session end data as an XML document within a hidden form 
field. As described above, in the instance of a shopping cart session, the order details 
(shopping cart) as a CBL format docimient within a hidden form field. 

An example of one embodiment practicing aspects of the present invention begins when a . 
user web browser is displaying ABC Motors Product Search page in which one or more 
motors have been selected. The user reads and selects one or more items. The user clicks on 
an "Order Form" link to submit the request. The ABC Motors order form page is served up 
by the ABC Motors server. The "Check Out" button sometimes used in e-commerce is 
replaced with the buyer application specified "Accept" button label. For example, the actual 
label may read "Add To a Requisition." The user clicks on the "Accept" button. This results 
in a HTTP/S Post to the ABC Motors server. The web browser is waiting for an HTTP 
Reply. The ABC Motors server HTTP/S Posts to the broker application the OrderRequest 
and context earlier provided by the broker application. The ABC Motors server is waiting 
for an HTTP Reply. The broker application HTTP/S Posts to the appropriate buyer 
application "Accept Order Request" ASP page for receiving the OrderRequest CBL and 
earlier provided buyer application context. The broker application is waiting for an HTTP 
Reply. The buyer application "Accept Order Request" ASP addes the items in the 
OrderRequest to the user's requisition (the buyer application context contains the user session 
information) and then HTTP/S Replies with HTML (to the broker appHcation). The broker 
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application HTTP/S Replies with the buyer application provided HTML to the ABC Motors 
server. The ABC Motors server HTTP/S Replies with the buyer application provided HTML 
to the usefs web browser. The user's web browser refreshes per the HTML. 

Due to the polymorphic nature of the message used to conclude the buyer-supplier 
session, the message is suitable for a variety of divers applications, including product 
configuration, tax calculations or freight forward, in addition to this shopping cart example. 
A further example of a tax calculation extension to ResponseData follows: 

<elementtype name="TaxCalculation"> 
<explain> 

<p>A <code>Tax</code> is typically returned from a 
RoundTrip session with a supplier's catalog or configurator. 
The <code>ShoppingCart</code> will containan <code> 
OrderReq uest</code> . </p> 

<p><code>OrderRequest</code> - an order request containing the 
itenns selected by and/or configured by the user from the supplier's 
web based catalog/configurator. </p> 
</explain> 

<extends type="ResponseData"> 
<append> 

<element prefix="cbl" type="Tax7> 
</append> 
</extends> 
</elementtype> 
</schema> 

Additional aspects of a system practicing the present invention may include forwarding a 
purchase order, as depicted in figure 2. Cancellation and error messages, referred to above, 
are described by schemas following the general form of the schemas presented in the 
examples. 

It is inherent in the present invention that methods practicing the present invention can 
be expressed as articles of manufacture by describing the method as embodied in a program 
stored on a magnetic medium. It is further inherent that those methods can be expressed as a 
broker server device running the broker portion of the method or as a system including buyer, 
broker and supplier servers running their respective portions of the method. 

While the present invention is disclosed by reference to the embodiments and examples 
detailed above, it is understood that these examples are intended in an illustrative rather than 
in a limiting sense. It is contemplated that modifications and combinations will readily occur 
to those skilled in the art, which modifications and combinations will be within the spirit of 
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the invention and the scope of the following claims. Each method practicing the present 
invention may readily be recast as a device or article of manufacture. 
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